工程師核對用 Block 與 Version。PM 與主管通常不想走進譜系，也不想在二十顆 block 上點二十次。他們要的是一張此刻的表：每顆葉子最新的實作怎麼樣、檢查過了沒有。Summary 就是這張表。它不是另一套資料，是同一堆上傳的 最新切片。美術可以體面，但體面建立在「最新」兩個字的定義夠硬。

這一頁有兩個入口：專案階層上的按鈕，看全部 block；Block 頁籤靠右的那扇門，只看當前這一顆。兩張表的欄位同一套，差在有沒有 block 欄。不要做成兩套邏輯，否則總有一邊會過期。

  專案階層 ──Latest summary──►  專案級摘要（每顆 block 一列）
       │                         APR 最新 ＋ SignOff 最新
       │點名字
       ▼
  Block 頁 ──靠右 Summary──►  同一組欄，只剩這一顆，不顯示 block 名

  樹上有、沒跑過的，仍占一列，寫「還沒跑」
  上傳裡多出來、樹上沒有的名字，不會在這裡長幽靈列

一、「最新」必須講死，而且兩種最新不要混

專案級摘要對階層裡出現的每一個名字各產兩列來源：最新一次 APR 上傳，以及最新一次帶 SignOff 的上傳。最新以 upload_date 字串比大小，新的在前。沒有 APR，那一列寫還沒跑。沒有檢查，那一列寫還沒有 SignOff。不要拿 ECO 的最新去填 APR 表，也不要拿最新 APR 的 DRC 去冒充檢查通過。

日期格式必須可排序。現場若有的寫 2026.07.18.12:00:00、有的寫 2026/7/8，字串排序會說謊，主管會看到「比較舊的」排成最新。這是資料契約，不是畫面 bug。TCL 出門時把時間寫成固定寬度、固定分隔，比在網頁上猜十二種日期更便宜。

「每顆 block 一列」來自階層，不是來自上傳。樹上有、沒跑過的，仍占一列，並明白寫還沒跑。這讓主管看見覆蓋率：二十顆裡五顆空白，是進度，不是表格壞了。上傳裡多出來、樹上沒有的名字，不會在這裡長出幽靈列。地圖仍以設計階層為準，與 Project 頁一致。

Block 級摘要只是把名字清單縮成當前這一顆。同一套「最新 APR、最新 SignOff」。PV 標稍後，表上不要先留假欄。假欄一出現，就會有人問數字為什麼是空的，會議會從內容滑向產品時程。

二、APR 表：一眼能問的幾個數

欄位要少，且每個都能在 Version 頁找到出處。建議就是現況這組：版本、stage、負責人、日期、runtime、DRC all、DRC short、DESIGN 利用率、繞路 violation 數。這些數從指標裡取出來時，該拆 { value: … } 的就拆。取不到就「—」，不要補零。

stage 在這裡常常是 cts、route 這類流程站名，不是 APR／ECO。它告訴你「最新一次實作停在哪一站」。與 Block 頁籤的 APR 不要搞混：頁籤是哪棵樹，欄位是那次 run 自己報的站。

列可點，進該次 run 的 Version 頁（APR 樹、該節點 id）。主管若只想看檢查，應去下一張表。不要在 APR 表加一顆燈號欄去複製 SignOff——複製會讓兩張表永遠有一張是過期的副本。想看燈號，看 SignOff 表。

負責人與 runtime 是給「這次是誰、跑多久」的口頭問題。它們不參與是否通過。不要因為 runtime 很短就在表上加顏色。顏色只留給檢查狀態。顏色一多，通過與否就不再唯一。

三、SignOff 表：給會議用的那一排燈

欄位：版本、QA 所在階段、track、日期、總燈號、通過數／總項、失敗、警告。點列進該 block 的 SignOff 門，不是進 Version。檢查的細節在檢查表，這裡只給判決與規模。

總燈號與 Block 頁同一套規則。會議上若只開 Summary，看到的紅、黃、綠必須與點進去之後相同。這是這座平台能不能被當「同一份現況」的最後一關。不一致時，先查是不是「最新檢查」與「你記得的那一次」不是同一份檔——Summary 永遠只展示最新，歷史在 Version 與葉子表。

track、QA stage 用來回答「這是哪一條簽核軌道、檢查掛在哪一站」。空著就空著。不要因為空白不好看而填 N/A；N/A 看起來像一個真的軌道名。

通過數寫成「過／總」比只寫百分比誠實。十三項過十三項，與兩項過兩項，百分比一樣，風險不同。主管不一定要懂每一項名字，但應該看到分母。

四、美術作業：體面來自掃得完，不是來自圖

Day 19 的原題把這一頁寫成「交給 PM 與主管的美術作業」。美術在這裡的意思是：讓人在投影機前三十秒掃完整張表，而不需要解釋元件。 不是漸層、不是插畫。

做得到的體面：兩張表同一套字體與間距；燈號只有四態；空白列用一句人話而不是空格子；表頭固定、橫向可捲但列首仍認得是哪顆 block；專案 id 寫在標題，回階層的按鈕在右上。做不到、也不該做的：首屏大餅圖、每顆 block 一張趨勢、自動把紅燈排到最上面——排序一自動，人就找不到「樹上的第幾顆」。維持階層順序，與 Project 頁同一條閱讀路徑，主管才能跟工程師用手指同一列。

若紅燈很多，人會要求「只看 FAIL」。那是過濾，可以日後加，但預設仍應是全表。覆蓋率本身就是資訊。只看紅燈的會議，會忘記還有哪些從來沒跑過。

標題寫 Latest run summary，底下補一句：每個類別一張表，PV 稍後。預期管理也是美術。沒寫的階段被問起來，你會被當成功能壞掉。

五、這頁怎樣接回工作台

摘要不是終點。每一列都要有下一跳。APR 列進譜系與並排指標，SignOff 列進檢查項。沒有下一跳的摘要，會議結束後工程師仍要再問「哪個版本」。有下一跳，主管可以在會議中把網址丟進聊天室，工程師打開就是同一筆最新。

反向也要成立。從 Version 或 SignOff 回到階層，再進 Summary，最新定義不變。不要在摘要自己快取一份更舊的數字。它每次都從讀檔整理的「最新上傳／最新檢查」現算。刷新，才跟磁碟對齊。

六、驗收給兩種觀眾各走一遍

工程師：對一顆你認得的 block，Summary 的 APR 版本應等於 Block APR 門最新葉子的版本；SignOff 燈號應等於檢查門標題上的燈號。點兩列，分別落到 Version 與 SignOff。空白的其他 block 寫還沒跑，而不是從表上消失。

主管：從大廳進專案，按 Latest summary，不需要再理解父親樹。能指出哪些紅、哪些還沒跑、最新日期是不是今天。把網址貼給別人，對方看到同一張表。

若兩種觀眾看到的「最新」不一樣，一定是日期不可排序，或有人把 ECO 混進 APR。修資料契約，不要在摘要頁加例外。例外會變成第二套最新，大廳就不再統一。

七、欄位從箱子的哪一格來，最好寫在紙上

APR 列不是隨便挑幾個好看的數。對應關係應能寫成一張小表：版本與負責人來自上傳外層；DRC all、short 來自指標 drc；利用率來自 urate 的 DESIGN；繞路來自 detour 的計數。寫得出來，換一個人抽數也不會抽錯格。寫不出來，Summary 會變成「程式裡寫死的魔術欄」，箱子一改版面就全空白。

SignOff 列同樣：總燈號來自計數推導，不是另存一個字串；通過／總項來自 pass_num 與 item_num。若箱子只給了 item_info 沒給計數，應在正規化時數過，而不是讓摘要去數。摘要只展示，不再發明判決。

專案級表的列序跟隨階層展平序，與 Project 頁同一條路。主管指「倒數第二顆紅的」，工程師在階層表也能指到同一顆。若摘要改成依燈號排序，這句話就失效。要加「紅的在前」當可選，預設仍是樹序。

沒有 APR 的列仍顯示 block 名，其餘合併成一句還沒跑。不要整列消失，也不要畫一排「—」讓人以為跑過但沒抽到數。人話比橫線清楚。點沒跑的列不應進一個空的 Version 節點；要嘛不可點，要嘛進 Block 的 APR 空狀態。現況若點了會找不到那一站，應走到「版本找不到」或根本不要當連結。這是小縫，修了會議上少一次「點了沒反應」。

ECO 為什麼不在摘要當第三張表？可以加，但第一版故意只有 APR 與 SignOff：主管問的是實作現況與檢查現況。ECO 仍在 Block 頁籤。摘要一張表加一種最新定義，就要再講一遍日期與混用問題。先兩張，穩了再加第三張，比一次三張但「最新 ECO」與「最新 APR」被看成同一列更安全。